Multiprotocol label switching (“MPLS”) provides a mechanism for engineering network traffic patterns in which short labels are assigned to network packets that describe how to forward them through a network (e.g., a packet switched network (“PSN”)). In a MPLS network, a node, switch or router which supports MPLS is generally known as a label switching router (“LSR”) and a LSR at the edge (ingress or egress) of the MPLS network is generally known as a label edge router (“LER”).
In general, as a data frame of a connectionless network layer protocol (e.g., the Internet Protocol (“IP”)) travels from a source node to a destination node it travels from one node to the next through the network. Each node makes an independent forwarding decision for that packet. That is, each node analyzes the data frame's header to determine where to forward the packet next. The forwarding decision is determined by a forwarding table that is present on each node and that is built by network layer routing algorithms running on that node. Therefore each router independently chooses a next hop for the data frame, based on its analysis of the packet's header and the results of running the routing algorithm.
Frame headers contain considerably more information than is needed simply to choose the next hop along the path. Choosing the next hop can therefore be thought of as the combination of two functions. The first function partitions the entire set of possible packets into a set of forwarding equivalence classes (“FECs”). In conventional IP forwarding, the FEC is a subnet IP address prefix. Therefore, a particular node will typically consider two packets to be in the same FEC if there is some address prefix “X” in that router's routing tables such that “X” is the “longest match” for each packet's destination address. The second function maps each FEC to a next hop. Insofar as the forwarding decision is concerned, different packets which get mapped into the same FEC are indistinguishable. All data frames which belong to a particular FEC and which travel from a particular node will follow the same path (or if certain kinds of multi-path routing are in use, they will all follow one of a set of paths associated with the FEC). As the data frame traverses the network, each hop in turn re-examines the packet and matches it to a FEC in order to determine the next hop.
In MPLS, the assignment of a particular data frame to a particular FEC is done just once, as the data frame enters the network. The FEC to which the packet is assigned is encoded as a short fixed length value known as a “label”. When a packet is forwarded to its next hop, the label is sent along with it; that is, the packets are “labeled” before they are forwarded. At subsequent hops, there is no further analysis of the data frame's network layer header. Rather, the label in the frame header is used as an index into a table on the node. The table entry specifies the next hop and a new label. The old label in the frame header is replaced with the new label and the data frame is forwarded to its next hop. Thus, in the MPLS forwarding paradigm, once a packet is assigned to a FEC, no further network layer header analysis is done by subsequent routers; all forwarding is driven by the labels.
For reference, the MPLS header is made up of a stack of 32 bit labels. The MPLS “label” is 20 bits long and is the identifier that is locally significant to the LSR. The “experimental bits” field is 3 bits long and is used to determine the quality of service (“QoS”) that is to be applied to the data frame. The “stack” field takes one bit and is used to determine whether there is another label stack entry in the header. And, the time-to-live (“TTL”) field is 8 bits long and is similar to the TTL field carried in the IP header and is used to determine how many hops the frame can traverse. The IP frame is encapsulated in with an MPLS header at the ingress edge of the MPLS network. At the egress edge, the IP frame is restored by removing the MPLS header.
The label distribution protocol (“LDP”) is used to build and maintain MPLS label databases that are used to forward traffic through MPLS networks. The LDP is specified in Internet Engineering Task Force (“IETF”) documents request for comment (“RFC”) 3036, “LDP Specification”, January 2001, and RFC 3037, “LDP Applicability”, January 2001, which are incorporated herein by reference. As mentioned above, MPLS is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two LSRs must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures (i.e., the LDP) by which one LSR informs another of label bindings it has made. Thus, the LDP is a set of procedures by which one LSR informs another of the meaning of labels used to forward traffic between and through them.
Now, a pseudo-wire (or pseudowire or “PW”) is an emulation of a native service over a packet switched network (“PSN”). The native service may be asynchronous transfer mode (“ATM”), Frame Relay, Ethernet, low-rate time-division multiplexing (“TDM”), or synchronous optical network/synchronous digital hierarchy (“SONET/SDH”), while the PSN may be a MPLS, IP, or Layer 2 tunneling protocol (“L2TP”) based network. The PW emulates the operation of a “transparent wire” carrying the native service. In other words, a PW emulates a point-to-point link and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service.
In general, a PW is a connection between two provider edge (“PE”) devices which connects two attachment circuits (“ACs”). An AC can be a Frame Relay data link connection identifier (“DLCI”), an ATM virtual path identifier/virtual channel identifier (“VPI/VCI”), an Ethernet port, a virtual local area network (“VLAN”), a high-level data link control (“HDLC”) link, a point-to-point protocol (“PPP”) connection on a physical interface, a PPP session from an L2TP tunnel, an MPLS label switched path (“LSP”), etc. During the setup of a PW, the two PEs will be configured or will automatically exchange information about the service to be emulated so that later they know how to process packets coming from the other end. After a PW is set up between two PEs, frames received by one PE from an AC are encapsulated and sent over the PW to the remote PE, where native frames are re-constructed and forwarded over the other AC. The PE devices may be, for example, MPLS switches, LERs, or LSRs.
PW extensions to the LDP are described in IETF document RFC 4447, “Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)”, April 2006, which is incorporated herein by reference. According to RFC 4447, Layer 2 services (such as Frame Relay, ATM, and Ethernet) can be “emulated” over an MPLS backbone by encapsulating the Layer 2 protocol data units (“PDUs”) and transmitting them over PWs. In other words, PWs are created to carry different types of traffic across a MPLS network, the PW being a point-to-point network connection over MPLS that offers transparency of the Layer 2 service which it transports.
RFC 4447 specifies a protocol for establishing and maintaining PWs, using extensions to the LDP. It defines new type-length-values (“TLVs”), FEC elements, parameters, and codes for LDP, which enable LDP to identify PWs and to signal attributes of PWs. It specifies how a PW endpoint uses these TLVs in LDP to bind a demultiplexor field value (i.e., an MPLS label as described above) to a PW, and how it informs the remote endpoint of the binding. It also specifies procedures for reporting PW status changes, for passing additional information about the PW as needed, and for releasing the bindings.
Consider the following RFC 4447 scenario. Suppose that it is desired to transport Layer 2 PDUs from ingress LSR PE1 to egress LSR PE2, across an intervening MPLS-enabled network. Assume that there is an MPLS tunnel from PE1 to PE2. That is, assume that PE1 can cause a packet to be delivered to PE2 by encapsulating the packet in an “MPLS tunnel header” and sending the result to one of its adjacencies. The MPLS tunnel is a MPLS label switched path (“LSP”); thus, putting on an MPLS tunnel encapsulation is a matter of pushing on an MPLS label. Also suppose that a large number of PWs can be carried through a single MPLS tunnel. Thus, it is never necessary to maintain state in the network core for individual PWs. It is not presupposed that the MPLS tunnels are point-to-point; although the PWs are point-to-point, the MPLS tunnels may be multipoint-to-point. It is not presupposed that PE2 will even be able to determine the MPLS tunnel through which a received packet was transmitted. (For example, if the MPLS tunnel is an LSP and penultimate hop popping is used, when the packet arrives at PE2 it will contain no information identifying the tunnel.) When PE2 receives a packet over a PW, it must be able to determine that the packet was in fact received over a PW, and it must be able to associate that packet with a particular PW. PE2 is able to do this by examining the MPLS label that serves as the PW demultiplexor field. This label may by called the “PW label”. When PE, sends a Layer 2 PDU to PE2, it creates an MPLS packet by adding the PW label to the packet, thus creating the first entry of the label stack. If the PSN tunnel is an MPLS LSP, the PE1 pushes another label (i.e., the tunnel label) onto the packet as the second entry of the label stack. The PW label is not visible again until the MPLS packet reaches PE2. PE2's disposition of the packet is based on the PW label.
Thus, a PW is a point-to-point connection across an MPLS network identified by a stack of two labels. The first label is called the “outer” label. It represents the outer tunnel, or outer LSP. This outer tunnel is needed to transport the packets across the network. Within this outer tunnel, “inner” connections (i.e., PWs) may be multiplexed. Each of these inner connections is identified by a second label, usually called the “inner” label. The outer tunnel is usually signalled (i.e., labels exchanged, etc.) using a protocol such as LDP or the resource reservation protocol-traffic extension (“RSVP-TE”). The inner connection (i.e., the PW) is signalled using LDP in its downstream unsolicited (“DU”) mode (i.e., “LDP-DU”). When LDP-DU mode is engaged, a LSR (e.g., a MPLS switch) can distribute MPLS label bindings to other LSRs that have not explicitly requested them. This label management behaviour is described in RFC 3036. Thus, the MPLS LDP-DU signalling protocol with PW extensions is thus used to establish bidirectional PWs across a MPLS network.
The PWs referred to above may also be referred to as single-segment pseudo-wires (“SS-PWs”) as they are setup directly between two terminating PEs (“T-PEs”). Each direction of the SS-PW traverses one PSN tunnel that connects the two T-PEs. Thus, a T-PE is a PE where the customer-facing attachment circuits (“ACs”) are bound to a PW forwarder. A PW may also have a number of segments. Such a PW may be referred to as a multi-segment pseudo-wire (“MS-PW”). Thus, a MS-PW is a static or dynamically configured set of two or more contiguous PW segments that behave and function as a single point-to-point PW. Each end of a MS-PW by definition terminates on a T-PE. That is, a T-PE is present in the first and last segments of a MS-PW. PEs located between T-PEs on a MS-PW are referred to as switching PEs (“S-PEs”). A S-PE is a PE capable of switching the control and data planes of the preceding and succeeding PW segments in a MS-PW. The S-PE terminates the PSN tunnels transporting the preceding and succeeding segments of the MS-PW. It is therefore a PW switching point for a MS-PW. A PW switching point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols to setup and manage PW segments with other PW switching points and T-PEs.
Now, as service providers (“SPs”) deploy PW services, fault detection and diagnostic mechanisms particularly for the PSN portion of the network are pivotal. Specifically, the ability to provide end-to-end fault detection and diagnostics for an emulated PW service is an important consideration for SPs. The term virtual circuit connection verification (“VCCV”) has been used to refer to a control channel that is associated with a SS-PW and to the corresponding operations and management functions such as connectivity verification to be used over that control channel. In general, VCCV defines a set of messages that are exchanged between PEs to verify connectivity of the SS-PW. To make sure that VCCV packets follow the same path as the SS-PW data flow, they are typically encapsulated with the same SS-PW demultiplexer and transported over the same PSN tunnel. For example, if MPLS is the PSN in use, then the same label shim header (and label stack) are typically incorporated. VCCV can be used both as a fault detection and/or a diagnostic tool for SS-PWs. An operator can periodically invoke VCCV for proactive connectivity verification on an active SS-PW, or on an ad hoc or as-needed as a means of manual connectivity verification. When invoking VCCV, the operator triggers a combination of one of its various connectivity check (“CC”) types and one of its various connectivity verification (“CV”) types. These include label switched path (“LSP”), L2TP, or Internet control message protocol (“ICMP”) ping modes and are applicable depending on the underlying PSN. For reference, term “ping” refers to an operation that may be used to test connectivity in a network. A ping operation sends an echo request packet to an address, and then awaits a reply. The result of the ping operation can help SPs evaluate path-to-host reliability, delays over the path, and whether the host can be reached or is functioning. For example, a ping operation may be is based on ICMP traffic and may use public routing tables in order to get to the required destination (if it exists). For reference, IETF document RFC 4379, “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures”, February 2006, which is incorporated herein by reference, describes MPLS “echo requests” and “echo replys” for the purposes of fault detection and isolation for MPLS label switched paths (“LSPs”).
However, for new MS-PW services, there is currently no effective method to easily pinpoint the point of failure and verify the end-to-end connectivity of a MS-PW. In particular, one problem with present MS-PW networks is that the control plane of the ingress node (i.e., the T-PE) of the MS-PW does not have access to the necessary information pertaining to the next segment of the MS-PW in order to format a VCCV echo request (or ping) and to allow for the successful validation of the echo request at the next segment of the MS-PW. While an operator of the network can manually perform a VCCV ping for each individual segment of the MS-PW one at a time, this is time consuming, not user-friendly, and requires the operator to have detailed knowledge of each segment of the whole MS-PW. In addition, such a manual approach may not even be possible if the operator does not have access to all the segments of the MS-PW (e.g., if the MS-PW spans the PSNs of different SPs).
A need therefore exists for an improved method and system for verifying connectivity of multi-segment pseudo-wires connections in packet switched networks. Accordingly, a solution that addresses, at least in part, the above and other shortcomings is desired.